REMARKS 

Reconsideration of the above-identified application, as amended, is 
respectfully requested. 

In the present Official Action, the Examiner first rejected Claims 1-32 under 
35 U.S.C. §102(e), as allegedly beuig anticipated by Ran et al. (US Patent No. 6,209,026) 
(hereinafter Ran), 

In response, as a preliminary matter, and without concedkig as to the propriety 
of the Ran reference, applicant cancels each of independent Claims 1, 14 and 23 and 
incorporates the subject matter thereof into respective 12, 22 and 32 now re-cast in 
independent form. These claims 12, 22 and 32 - now independent claims, had originally set 
forth the uiventive system and method step of placmg the device in a "sleep" mode of 
operation and further implementing an alarm mechanism for placing the wireless data receiver 
device from the sleep mode to a receive mode for receiving the wireless data communications . 

These independent Claims 12, 22 and 32 have been amended herein to further 
clarify that the present invention includes enabling the user to specify, in a data request, a 
request for receiving data at a requested future time and location . Respectfully, no new matter 
is being entered as page 21, lines 24- 33, page 22, lines 15, et seq. and Fig. 7(b), at steps 852 - 
859, describe the use of the present invention for enabling users to specify a location at which 
the requested data information is to be sent to the user device, e.g., through a wneless (e.g., 
Bluetooth) beacon that is located near the user's device, e.g., step 855 (Fig. 7(b)), e.g., in a 
building. Thus, now amended independent Clauns 12, 22 and 32 including the feature for 
enabling the device to be placed in a sleep mode of operation and ftirther implement an alarm 
mechanism for placing the wireless data receiver device from the sleep mode to a receive 
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mode enables user receipt of requested information via the wireless data communications in 
synchronism with user availability at said user-specified future time and location . 

Thus, the user does not have to actively participate in receiving the actual data 
transmission at the requested future tune and location, i.e., the wearable appliance implements 
a built-in alarm mechanism that enables the wireless data receiver device to receive the 
requested wireless transmission at the specified time and location without requiring fijrther 
user participation during the transmission. 

These features of amended now independent Claims 12, 22 and 32 clarify 
further novel aspects of the present invention that are neither taught nor suggested by Ran: 
namely, that it provides users with an asynchronous demand-pull fimctionality for a wearable 
digital appliance (e.g., a "smart" watch) that implements a wireless data receiver device by 
providing a method for communicating data to the wearable appliance so that the device may 
receive wireless data communications at a user-specified time and location and without user 
participation. User participation is not required in the present invention as the user device 
may be programmed to awake the data receiving channel from a sleep mode of operation to 
automatically wake up just before the receiving the data transmission at the requested time 
and location if no other application on the device needs to use the receiving communication 
channel. 

Respectftilly, notwithstanding the Examiner's rejection of Claims 12, 22 and 
32 in the Office Action, appUcant submits that Ran does not teach the notion of powering any 
data receive device off At the cited passage m Ran at col. 6, lines 17-25, relied upon by tiie 
Examiner in her rejection of Claims 12, 22 and 32, there only appears a teaching of a host 
server that can prepare the data in a format suitable for a particular wireless device and 
transmit it to a user device "based on a user-defined frequency". Applicant is hard-pressed to 
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find how this is a teaching of a sleep/alarm mode of a wearable appliance that enables the 
wireless data receiver device to receive the requested wireless transmission at a specified time 
and location without requiring further user particination during said transmission . That is, 
Ran does not appear to provide for the scenario if a data receipt device contemplated by Ran 
is sleeping or off, but rather appears to assume that the devices are "on" and assumed 
available to receive data. 

Thus, in such a scenario, the Ran device will waste energy. Ran also does not 
specify what device the data will be delivered to - it appears all devices that are registered 
devices in the Ran system will receive the data, further wasting bandwidth, storage and 
electrical power. 

Thus, effectively, Ran teaches a real-time processing "pull" infirastructure 
whereby, a user transmits a data request for essentially "time critical" information, e.g., real- 
time traffic, warnings, information, which is promptly gathered at a central server via a 
variety of resources, and formatted for transmission back to the same requesting device. 

Ran does not provide a teaching or suggestion of a user request that specifies a 
time and location for delivery of information . Ran is a web-based system that will actually 
suffer firom information overload since a user of the Ran device may receive irrelevant 
information about certain traffic data that would be largely irrelevant to the user (e.g., a user 
may receive information about the Whitestone Bridge when he is Westchester and has no 
mtention of crossing the bridge.) 

Moreover, it is respectftilly submitted that Ran's notion of transmitting 
requested data at a "user-defined fi:equency" is interpreted to mean once a day, once X 
minutes, etc., but not at a specific time. That is, firequency commonly means a periodic event, 
not a definable schedule. Thus, a user that wants to hit a series of times with a fi-equency, for 
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example, a user who wants delivery at 1.20pm, 1.23pm, 1.27pm, 1.32pm, 1.39pm, and 
1.50pm, etc., no frequency can be specified, the time deltas of 3 minutes, 4 minutes, 5 
minutes, 7 minutes, 11 etc, have no common factor. Thus, to enable this, using Ran, a user 
would have to send a request to hit all these times by programming Ran to send the requested 
data to the user every "1 minute" - which will waste bandvddth and annoy the user. Ran, 
furthermore, does not appear to teach this frequency granularity for transmitting the data. 

Again, respectfully, even though Ran suggests processing data updates at a 
user-defined frequency, this really connotes a subscribe/push scenario where the requested 
data is automatically updated and "pushed" to the user device at specified intervals with no 
guarantee that a user is even present to receive the updates and, which constitutes: a waste of 
resources, bandwidth memory storage, that the present invention is configured to avoid. 

The present invention is rather directed to satisfying an asynchronous request 
for data, e.g., which maybe locally present not gathered from the Intemet, unlike in Ran, and 
received via a first communications means, and further transmitted to a user for receipt at a 
wearable appliance via a second wireless communications means at a user-specified time and 
location that ensures user availabihty, i.e., an asynchronous "demand pull" model. 

Further functionality of the invention is provided in new Claims 33-34 
dependent upon amended independent claims 12 and 22, which set forth the notion that user 
selection options may be set in advance and at data request time, to specify what data needs to 
be sent and when. For example, new Claim 34 sets forth a step of: providing pre-determined 
personalized selectable menu option choices to a user for user selection at a time of making a 
data request, said pre-determined personalized selectable menu option choices relatmg to 
requests for receipt of data associated with two or more user applications each adapted for 
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execution on said user hand-held device, and which data is received and maintained for users 
as part of said associated user applications, 

wherein a user is enabled to set specific data delivery options in advance or at 
data request time to specify, via said menu options, what data needs to be sent and the user- 
specified time. 

Full support for new Claims 33 and 34 is found in the specification for 
example, in the paragraph bridgmg pages 17 and 18 of the specification which describes 
various menu option choices that may be pre-detennined and may comprise requests for data 
associated with two or more user applications that are each adapted for executing on said user 
hand-held device, e.g., a calendar/appointment book information firom a calendar or an 
address book application, or all e-mail headers since a last time retrieved from an executable 
e-mail program, or only messages firom a management or a day care center, or stock quotes 
lirom a financial soflware apphcation package, etc. 

These new Clauns 33 and 34 respectfully differentiate over Ran, as agaiu, Ran 
focuses on specifying real-time information for travel -only. The present invention, on the 
other hand, is neither focused on the receipt of real time information nor travel information, 
and fiirther is not necessarily concerned with the real time nature of information as Ran's 
invention. 

For all the foregoing, applicant respectfully submits that new independent Claims 12, 
22 and 32 are patentably distinct over Ran, and the Examiner is respectfliUy requested to 
withdraw the rejections of all claims under 35 U.S.C. §1 02(e) and to allow these claims and 
new Claims 33 and 34 to proceed to issuance. Present Claims 2, 10, 1 1, 14 and 24 are being 
amended herein to change their dependency in view of the cancellation of original 
independent Claims 1, 13 and 32. 
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In view of the foregoing remarks herein, it is respectfully submitted that this 
application is in condition for allowance. Accordingly, it is respectfully requested that this 
application be allowed and a Notice of Allowance be issued. If the Examiner believes that a 
telephone conference with the Applicants' attorneys would be advantageous to the disposition 
of this case, the Examiner is requested to telephone the undersigned, Apphcants' attorney, at 
the followmg telephone number: (516) 742-4343. 



Respectfully submitted. 




Steven Fischman 
Registration No, 34,594 



Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, New York 11530 
(516) 742-4343 
SF:gc 
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